First Reports from the UVM Trenches: User-friendly, Versatile and Malleable, or just the Emperor's New Methodology?

For us, UVM arrived at exactly the right time. Our large new project evidently called for more powerful verification techniques than its predecessors. At the same time, a change of tool chain was on the horizon, bringing cross-vendor compatibility concerns to the fore. Finally, many members of the team were beginning to take their first steps in OOP and constrained-random verification, making it essential to establish a robust framework that could be stable for the foreseeable future, while offering a growth path that would match our developing needs. This paper reports on some of the successes, pitfalls, unexpected problems and unanticipated delights of our UVM rollout. Our project was making day-to-day use of UVM verification components within two weeks of the Early Adopter release, leveraging previous OVM experience of some members of the team. Several months on, our in-house UVM library is burgeoning in size and flexibility. Real bugs in our design have been found and fixed, and our first predominantly UVM-verified tapeouts are due as this paper goes to press. Starting from a plain-old-SystemVerilog methodology that worked well but had limited room to grow, numerous members of the team have transitioned to SystemVerilog OOP with the help of UVM, aided by a strong existing culture of re-use. Not everything about our UVM experience was positive. Aside from the handful of minor shortcomings in the UVM library that any early adopter must expect to live with, we describe some important things that we had hoped UVM would provide but which we have been obliged to build from scratch. We also report on challenges we faced in ensuring consistency of approach among team members, incorporating existing verification assets into our UVM framework, and getting the best out of the whole team’s skills. In the paper we review key aspects of our UVM experience, giving special attention to the match (or mismatch) between UVM advocacy we’ve heard and the UVM features that we found were most productive. Examining several specific technical issues in detail, we highlight areas where we have chosen to abandon established or published recommendations in favour of a more radical approach. Finally we assess the overall productivity gains and losses that UVM brought, and identify key concerns that we believe the UVM community must soon address to avoid the unpleasant prospect of large numbers of users each with their own incompatible implementations.